1. Field of the Invention
Embodiments of the present invention relate to data processing. In particular, methods and systems for redisplaying viewable entities are provided.
2. Background of the Related Art
In a user interface (UI) environment objects, such as windows, can be displayed. Where multiple instances of windows exist, the windows can overlap each other such that one window may partially or completely obscure another window. A window may also be ‘minimized’ such that the window is represented as an icon on the user interface or might even be completely hidden from the user interface.
In a user interface hosting a windows environment, the user may request an action on an object that causes a window to be displayed. Then, before the window is closed, the user may request the same action on the same object again. In this case, the computer system may be configured for various methods of responding to the user's request. In one configuration, the application that displays the window may only allow one instance of the application to be active at a time. Accordingly, only one instance of the application's window can be displayed to the user at a time. If only one instance of the application/window is allowed, and the user requests to start a second instance of the application, then the application would detect that the an instance is already running and takes steps to prevent a second instance of the application from starting.
Typically, these types of applications do not deal with specific objects, but rather have a system-wide or signed-on-user scope. For example, an e-mail application might be designed such that the user can only have one instance of the application/window active at a time. Another example is the Windows Task Manager.
In an alternative configuration, the application that displays the window may allow more than one instance of the application to be active at a time. Since many instances of the application can be running simultaneously, there can be many instances of the application's window displayed to the user at a time. For example, properties windows for several files might be displayed simultaneously. Typically, these types of applications deal with specific objects.
For the first configuration, in which only one instance of the application is permitted, the application may react in one of various ways to the user's request to start the application a second time. For example, the user's second request to start the application may be ignored. Alternatively, an error message may be issued telling the user that the application is already active. Still another approach is to allow a second instance of the application to run just long enough to detect that the first instance of the application is already running and notify the first instance of the application that the user wants to see the application. The second instance of the application would then exit. The first instance of the application would then make itself visible (e.g., bring itself to the foreground, unminimize itself, etc.). In this last approach multiple objects can be simultaneously acted upon by the single instance of the application. For example, if the first action was to edit file Xyz and the second action was to edit file Abc, then a single instance of edit application would still be enforced, but the application would internally manage multiple files that are being edited via a mechanism such as a file list.
The second configuration, in which multiple instances of the application are permitted, may also provide various ways in which the application handles the user's request to start the application a second time. Of particular interest is how the application handles a user's request to display the application/window for an object that is already being operated on by another instance of the application. In one implementation, if the application/window for the object is already active, the user's second request to display application/window is ignored. In another implementation, the user is given an error message indicating that the application/window for the object is already active. In still another implementation, a second instance of the application/window for the object is displayed to the user, even if an instance is already active for the object that the user started the application for. For example, suppose the original action was to edit file Xyz and an edit window for file Xyz was displayed to the user. When the user requests to edit file Xyz again, a second edit window for file Xyz is displayed and the user would have two edit sessions for file Xyz active at the same time. In still another implementation, if the application/window is already active for the object being acted upon, then the existing window for that object is made visible (brought to the foreground, unminimized, etc.). Otherwise, a new window is displayed for the object. For example, suppose the original action was to edit file Xyz and an edit window for file Xyz was displayed to the user. When the user requests to edit file Xyz a second time, the previously-created edit window for file Xyz is shown to the user and the user would still have just one edit session for file Xyz. However, if the second action is to edit file Abc, then a second edit window is created for file Abc. Thus, the user would have two edit windows open simultaneously, but they would be for different files.
This last implementation is particular advantageous in a multiple windows environment in which users desire to move between the windows and require that only one instance of an application for a given object exist to avoid creating conflicts. The windows management facilitated by this implementation gives users confidence to operate in the multiple windows environment.
However, one problem with this last implementation is its reliance on a platform-specific mechanism to keep track of whether or not a particular window is active. In this context, a ‘platform’ is defined to be the environment that an application runs in. The platform provides certain operating and programming interfaces that the application can use to perform its functions. Examples of platforms include operating systems, such as Windows, Linux, OS/400, the Palm Pilot OS, etc. The Windows Registry is an example of a platform-specific interface. For example, the Windows Registry might be used to store information about active windows.
Platform-dependant implementations are adequate if the application is intended to only run on one platform. However, this design requires code modifications (porting) in order to make the application run on platforms other than the one it was originally written for. For example, an application that was written for Windows and used the Windows Registry would need to be modified to use a replacement for the Windows Registry in order to run on Linux. Therefore, it is desirable for the implementation to be platform-independant so that the application can provide the desired behavior on multiple platforms without modification.
Another limitation of current windows management implementations is redundant code. Some designs could require that each application provide code to implement the mechanism of keeping track of its windows. This leads to duplication of effort in developing the application. Accordingly, it is desirable for the implementation to provide a common set of code for storing and managing the set of active windows. Applications requiring this capability can then just use the predefined functions, rather than re-implementing them. This results in efficient code development.
Another disadvantage to conventional windows management implementations is their complexity. Within a given UI environment, there could be several applications that each implement their own method(s) of keeping track of active windows. This leads to complexity, especially if there is code outside of those applications that needs to “know” how to access each application's active windows. Accordingly, it is desirable to provide a single implementation for storing and managing the set of active windows in order to simply the application environment.
Therefore, what is needed is a method and system for keeping track of active windows such that if the user requests to display a window that is already active, the existing window can be located and arranged to be viewable. Preferably, the implementation method provided is platform independent, avoids redundant code, and is sufficiently simple for applications to code to.